创建时间: | 2017/3/7 11:54 |
来源: | http://www.cnblogs.com/moss_tan_jun/p/6021822.html |
为了优化SQL语句的排序性能,最好的情况是避免排序,合理利用索引是一个不错的方法。因为索引本身也是有序的,如果在需要排序的字段上面建立了合适的索引,那么就可以跳过排序的过程,提高SQL的查询速度。下面我通过一些典型的SQL来说明哪些SQL可以利用索引减少排序,哪些SQL不能。假设t1表存在索引key1(key_part1,key_part2),key2(key2) a.可以利用索引避免排序的SQL
b.不能利用索引避免排序的SQL
2.排序实现的算法 假设表结构和SQL语句如下: CREATE TABLE t1(id int, col1 varchar(64), col2 varchar(64), col3 varchar(64), PRIMARY KEY(id),key(col1,col2)); SELECT col1,col2,col3 FROM t1 WHERE col1>100 ORDER BY col2; a.常规排序,双路排序 3.排序不一致问题 案例1:order by no_index limit n在MySQL5.5和5.6中的不一致 MySQL从5.5迁移到5.6以后,发现分页出现了重复值(排序字段没有用索引,或则直接是全表扫描),MariaDB已经是优化后的方案,和5.6一致。 问题源头:https://bbs.aliyun.com/read/248026.html,解决办法:http://mysql.taobao.org/monthly/2015/06/04/ 测试表与数据: create table t1(id int primary key, c1 int, c2 varchar(128)); insert into t1 values(1,1,'a'); insert into t1 values(2,2,'b'); insert into t1 values(3,2,'c'); insert into t1 values(4,2,'d'); insert into t1 values(5,3,'e'); insert into t1 values(6,4,'f'); insert into t1 values(7,5,'g'); 假设每页3条记录,第一页limit 0,3和第二页limit 3,3查询结果如下: 我们可以看到 id为4的这条记录居然同时出现在两次查询中,这明显是不符合预期的,而且在5.5版本中没有这个问题。 使用优先队列排序的目的就是在不能使用索引有序性的时候,如果要排序,并且使用了limit n,那么只需要在排序的过程中,保留n条记录即可,这样虽然不能解决所有记录都需要排序的开销,但是只需要 sort buffer 少量的内存就可以完成排序,上面已经说明。 之所以MySQL5.6出现了第二页数据重复的问题,是因为使用了优先队列排序,其使用了堆排序的排序方法,而堆排序是一个不稳定的排序方法,也就是相同的值(例子中的值2)可能排序出来的数据和读出来的数据顺序不一致,无法保证排序前后数据位置的一致,所以导致分页重复的现象。 为了避免这个问题,有几种方法: ①:索引排序字段 利用索引的有序性,在字段添加上索引,就直接按照索引的有序性进行读取并分页,从而可以规避遇到的这个问题。 ②:利用多列索引,对于单列相同无法排序的,利用其主键进行排序: select * from t1 order by c1,id asc limit 0,3; select * from t1 order by c1,id asc limit 3,3; 案例2:单路排序和双路排序返回结果不一样 两个类似的查询语句,除了返回列不同,其它都相同,但排序的结果不一致。 测试表与数据: create table t2(id int primary key, status int, c1 varchar(255),c2 varchar(255),c3 varchar(255),key(c1)); insert into t2 values(7,1,'a',repeat('a',255),repeat('a',255)); insert into t2 values(6,2,'b',repeat('a',255),repeat('a',255)); insert into t2 values(5,2,'c',repeat('a',255),repeat('a',255)); insert into t2 values(4,2,'a',repeat('a',255),repeat('a',255)); insert into t2 values(3,3,'b',repeat('a',255),repeat('a',255)); insert into t2 values(2,4,'c',repeat('a',255),repeat('a',255)); insert into t2 values(1,5,'a',repeat('a',255),repeat('a',255)); 分别执行SQL语句: select id,status,c1,c2 from t2 force index(c1) where c1>='b' order by status; select id,status from t2 force index(c1) where c1>='b' order by status; 执行结果如下: 看看两者的执行计划是否相同 为了说明问题,因为测试数据不多,确保能走上c1列索引,加了force index的hint。语句通过c1列索引取id,然后去表中捞取返回的列。根据c1列值的大小,记录在c1索引中的相对位置如下: (c1,id)<===>(b,6),(b,3),(c,5),(c,2), 对应的status值分别为2,3,2,4。从表中取数据并按status排序,则相对位置变为(6,2,b),(5,2,c),(3,3,b),(2,4,c),这就是第二条语句查询返回的结果,那么为什么第一条查询语句(6,2,b),(5,2,c)是调换顺序的呢? 这里说明下: 之前提到的优化排序就可以明白了:由于第一条查询返回的列的字节数超过了max_length_for_sort_data,导致排序采用常规排序,而在这种情况下第二次IO时,MYSQL本身优化会对id排序,将随机IO转为顺序IO,所以返回的先是5,后是6;而第二条查询采用的是优化排序,没有第二次取数据的过程,保持了排序后记录的相对位置,直接在sort buffer里取出。对于第一条语句,若想采用优化排序,我们将max_length_for_sort_data设置调大即可,比如2048。 |